This section is intended to provide a background to the various embodiments of the technology described in this disclosure. The description in this section may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and/or claims of this disclosure and is not admitted to be prior art by the mere inclusion in this section.
In general, a Physical Downlink Control Channel (PDCCH) carries a message known as Downlink Control Information (DCI), which includes resource assignments and other control information for a UE or group of UEs.
There are several different message formats are available for DCI. Format 0 (also referred to as DCI0) contains fields indicating Modulation & Coding information of user plane data in Physical Uplink Shared Channel (PUSCH) from UE so that UE can do correct encoding of uplink (UL) data (the fields may be called as fields for uplink control). The other formats (including format 1, 1A, 1 B, 1C, 2, 2A, 2B, also referred to as DCI1, DCI1A, DCI1 B, DCI1C, DCI2, DCI2A, DCI2B respectively) include fields indicating Modulation & Coding information of user plane data in Physical Downlink Shared Channel (PDSCH) to UE so that UE can do correct decoding of downlink (DL) data (the fields may be called as fields for downlink control).
FIG. 1 illustrates some typical fields in DCI indicating Modulation & Coding information. As shown in FIG. 1, fields for downlink control include Modulation Coding Scheme (MCS) of five bits, Redundancy Version (RV) of two bits and New Data Indicator (NDI) of one bit. As to fields for uplink control, RV is combined with MCS, so there are six bits in total. Hereinafter, such fields will be generally referred to as a MCS layout.
FIG. 2 illustrates the existing PDSCH and PUSCH decoding procedure. As illustrated, for downlink control corresponding to PDSCH decoding, MCS is on one hand used as an input index to look up a table in the existing 3GPP 36.213 specifications to decide the real Transport Block (TB) size, and on the other hand also indicates modulation mode. There is a similar process for uplink control corresponding to PUSCH decoding.
However, the existing solutions have the following problems:                Downlink control needs 8 bits to indicate all necessary information, while uplink control only needs 6 bits. Such an asymmetric design makes uplink have to employ different processing from downlink even if most of MCS handling semantics are exactly the same.        Among the 32 values indicated by 5 bits MCS, the last three values (29, 30, and 31) are reserved to indicate the modulation mode in downlink retransmission. In other word, only 29 out of 32 values are used as the input index to decide the TB size. Such a special design not only introduces extra complexity in decoding, but also reduces valid TB size ranks from 32 to 29, thereby resulting in unnecessary accuracy loss for the TB size.        As to MCS layout for uplink control, since RV is combined with MCS into 5 bits MCS, there is no more room to indicate the modulation mode at retransmission. So, it imposes another constraint that uplink retransmission at RV1, RV2 or RV3 has to keep the same modulation mode as RV0, which limits the flexibility during uplink retransmission and may result in throughput loss.        If BS can't find the same TB size from the table of FIG. 1 during retransmission as that in initial transmission, it has to use the reserved 29, 30 or 31 at retransmission. However, here is a premise that UE must already know the initial TB size, otherwise UE will always fail to decode data regardless how many times of retransmission. Unfortunately, such a premise is NOT always true. If the initial transmission (RV0) is lost at UE unexpectedly, but BS has no idea about it, UE cannot recover from the subsequent HARQ retransmission except of RLC layer retransmission.        